Electronic communication is an essential tool in facilitating both business and personal communication. One form of electronic messaging, email, offers several advantages over traditional forms of communication. Email allows for the almost instantaneous exchange of information, it allows for the transmission of multiple messages at very little cost and it permits the transfer of large data files from one sender to another user. Nonetheless, the inherent nature of email gives rise to certain disadvantages. Most notable, and a topic of critical concern, is the increasing proliferation of unwanted and unsolicited email or “Spam.”
Spam is unsolicited email that is typically transmitted to an extremely large number of email recipients. Spam is the electronic equivalent to “junk mail” received by traditional mail service. Generally, a Spam email is a commercial advertisement attempting to sell a product or service. Spam typically directs the recipient to take some action in order to purchase the product or service being advertised. This may be in the form of offering a phone number or a hyperlink in the text of the spam message which, when utilized by the recipient will place the recipient in contact with the seller of the goods or services. Spam is often, although not exclusively, utilized by entities marketing products or services outside the norm of traditional retailers and service providers. Some Spam messages contain information or graphics unsuitable for all email users, particularly those who are children. However, Spam offers tremendous marketing benefits as it allows a retailer, marketer, or other sender to reach an incredibly large audience with a minimal economic expenditure.
Unfortunately, this benefit to the sender of Spam comes at a considerable cost to the unwilling recipients of Spam messages. Spamming costs companies millions of dollars in congested servers, expenses incurred employing measures to block the Spam email, and lost productivity due to email recipients having to wade through large amounts of Spam solicitations in order to find desired email. Further, Spam email provides an ideal medium for computer hackers to infect users' systems through the introduction of computer viruses and other malicious code.
Persons who desire to send Spam email are able to obtain email lists in a variety of ways. For example, email lists can be compiled from email addresses appearing on existing emails received by the sender or from users who provide their email address during electronic transactions. Additionally, lists of addresses are often compiled by third parties and sold in the same manner that traditional address lists have been sold.
According to one estimate, as of January 2004, Spam email constituted as much as 60% of all email traffic on the Internet (“Microsoft Sets Its Sights on Defeating Spam,” National Public Radio, Morning Edition, Feb. 2, 2004). As Spam has become more plentiful, there has arisen a great demand for an effective and efficient method which will detect and block delivery of these unsolicited messages.
Spam email, like all email, originates from a Sending Email System. All electronic messages, including Spam email messages, contain various data elements in a header, an envelope or another designated portion of the electronic message that facilitate transfer of the message. These include, most especially, the addresses of the intended recipients of the message, the address of the originator of the message and the date and time when the message was prepared. For example, under Internet standard RFC 2821, “Simple Mail Transfer Protocol,” the message envelope of an email contains various data elements including an originator address and one or more recipient addresses. Similarly, under standard RFC 2822, “Internet Message Format” an internet message header for an email must contain an origination date and an originator address and typically includes a destination address field.
An email address, whether an originator or a recipient address, typically takes the form of “user@domain name.” For either originator or recipient addresses, the domain name portion of the email address identifies the host system to which or from which email is sent or received. The “user” portion of the address identifies the specified user and is assigned by the host system which, in the case of an originator address, transmits emails prepared by the specified user or, in the case of a recipient address, receives email messages for the specified user.
A host system sending an email transfers email to an intended recipient by referencing the Domain Name System (“DNS”). When the sending host system receives a prepared email message, it first identifies the domain name for each of the intended recipients. Through processes well known to those schooled in the art, the sending host system then utilizes the Domain Name System (“DNS”) to determine the Internet Protocol (IP) address of the host system associated with each of the domain names in each of the recipient email addresses.
Next, the sending host system communicates with each host system associated with an intended recipient utilizing an email transfer protocol. For example, RFC 2821, “Simple Mail Transfer Protocol,” (“SMTP”) describes one protocol typically used for the transfer of electronic messages.
Although a sending host system could communicate with a receiving host system over any one of the more than 65,000 communication ports available to either system, by convention email transmissions are typically conducted through one or more designated ports. For example, the Internet Assigned Numbers Authority (“IANA”) has designated communication ports numbered 0 through 1023 as System or Well Known Ports and further designated port 25 for Simple Mail Transfer. See http://www.iana.org/numbers.html. Accordingly, by convention most SMTP processes are conducted by electronic communications between a sending host system's port 25 and a receiving host system's port 25.
Where a host system comprises a plurality of email servers servicing a single domain name, the DNS system provides one or more IP addresses for access to any of the servers. Thus, where a receiving email system may receive messages by a plurality of email servers, any sender querying the DNS system will receive the same unique IP address or set of unique IP addresses for the domain name. When an email or other electronic communication is made to the IP address, the receiving email system, through processes well known to those schooled in the art directs the transmission to the appropriate server within the receiving system.
DNS data may be stored at the individual client machine level as well as at the host system level. Additionally, DNS name servers are available through the Internet for inquiries that cannot be satisfied at the client machine or host system level.
As noted earlier, one data element customarily included in an email message is the email address from which the email originated. For example, an email user who prepared a message conforming to RFC 2822 would include an originating email address in the “From:” email header field such as “From: user@domain.com” in which “domain.com” is the domain name from which the message originated. Optionally, an originating email address, including a domain name, may appear in the “Sender:” email header field.
One partially effective method of blocking Spam messages known by those schooled in the art is for a Receiving Email System to identify the domains from which Spam is known to originate and then to block any future emails which are sent with originating email addresses that have that same domain name. A Receiving Email System simply compiles a list of the domain names which have sent Spam messages. This list, or “blacklist,” is thereafter, referenced by the Receiving Email System whenever an email is received. If the email originated from a domain name on the blacklist, the message is blocked from delivery.
Those skilled in the art will recognize that the Inverse of this technique can be, and has also been, implemented. That is, a Receiving Email System may compile a list of trusted domain names, or a “whitelist.” Thereafter, whenever a message is received by the Receiving Email System the whitelist is referenced. If the message originated from a domain name on the whitelist, the message is delivered.
Many Receiving Email Systems employ both whitelists and blacklists. If the source domain is recognized as a trusted system because it is listed on the whitelist, the email is delivered. If it is not, the Receiving Email System references a blacklist to determine whether the source has been identified as a source of Spam email and refuses delivery if it has been so identified.
Several services, such as SpamCop and MAPS, have been formed to compile, maintain and share the domain data of known spamming domains. These services allow Receiving Email Systems to reference large databases of known sources of Spam email compiled from many sources so that the Receiving Email System participating in the service may exclude email originating from a domain known to be a source of Spam email. This method of filtering unsolicited email has been implemented at both the user level, the Receiving Email System level, as well as the Internet Service Providers (ISP) level. As a matter of reference, it is estimated that ISP America On-Line blocks almost 2 billion messages per day from identified spamming systems.
However, an increasing amount of Spam is bypassing blacklist measures and capitalizing on whitelists by “spoofing” itself as having originated from legitimate domains. Spoofing occurs when a spamming system provides a false originating email address as a data element in the email or the email envelope. The domain name of the false address may be a legitimate domain name, such as “aol.com,” hotmail.com,” or “msn.com,” or it may be a fictitious domain name. Spammers falsify or “spoof” the originating email address in a Spam message in order to bypass blacklists that are blocking Spam and to hide their actual identity from Receiving Email Systems. Because there is a plethora of legitimate domain names from which legitimate email might originate, a spamming system utilizing spoofing has an almost unlimited ability to conceal its identity from Receiving Email Systems by frequently changing the domain name which it falsely provides as the source of the Spam messages being sent. As a matter of reference, it has been estimated that 70% of all Spam contains a spoofed originating email address.
Spoofing further compromises the ability of a Receiving Email System to use blacklists or whitelists to block Spam because of the potential for blocking legitimate and desired email transmissions. For example, a spammer may configure the spamming email system to send out Spam with an originating email address in the message header that identifies “hotmail.com” as the domain name from which the Spam email originated. In such a circumstance, email systems which receive these Spam messages and which utilize blacklists are faced with a dilemma. Although they could block all emails originating from the hotmail.com domain, this would have the undesirable effect of also blocking all non-Spam, desired emails coming from hotmail.com users.
Accordingly, if a Receiving Email System relies upon blacklists and whitelists only to block Spam it must either deliver spoofed Spam email or deny delivery of a significant amount of desired email. The first shortcoming occurs when a Spammer spoofs a domain name which exists on the Receiving Email System's trusted domain name list, that is, its whitelist. The second occurs when the Receiving Email System identifies a domain as a spamming domain and provides the domain data for that domain to a local or centrally maintained blacklist because the domain name was falsely shown as the originating domain for Spam email. Thereafter, when non-Spam email is originated from the domain and transmitted to the same Receiving Email System or to another Receiving Email System which references the same blacklist, the non-Spam email will be blocked.
The spoofing problem is further exacerbated by the inability of system administrators to identify all potential domain names from which non-Spam email might originate. Therefore, it has become increasingly difficult for system administrators to avoid blocking legitimate email while simultaneously stopping “spoofed” Spam because they cannot blacklist and block domain names that are heavily utilized by legitimate email senders and because they cannot be certain that some desired email will not be blocked if they add a previously unidentified spamming domain name to a blacklist.
Spoofing also facilitates another undesirable practice in electronic messaging: “phishing.” Phishing is an attempt to obtain information from an email recipient by falsely representing to be a person or entity entitled to receive such information or by falsely claiming a need for such information. For example, a phisher may send an email which is spoofed with a false origination address which appears to be a legitimate email address for a financial institution, e.g. “customerservice@chase.com.” The text of the email may request that the recipient respond by providing his or her account number, social security number, address or other sensitive information which may thereafter be used illicitly by the phisher. Alternatively, the email might direct the recipient to a web site at which the recipient is requested to provide sensitive information. Accomplished phishers frequently employ brand names and marks similar to the entity whose email address is spoofed so that it is difficult for even sophisticated recipients to recognize a phishing attempt. Phishing has become so prevalent and well-known, and the consequences of phishing are so severe, that customers who receive legitimate email messages are often reluctant to respond to these because they fear that the email may be a phishing attempt.
Phishing and spamming and the implementation of ineffective methods for blocking Spam present an especially difficult problem for those who use or desire to use electronic messaging in commerce. In commercial transactions it is frequently necessary to be able to demonstrate that an electronic message was received by the intended recipient. For example, where the message constitutes a demand for payment or where the message delivers goods or services, it is desirable for the sender to be able to verify delivery of the message to the intended recipient. If a Receiving Email System utilizes less than optimal Spam detection and elimination techniques, a desired message may not be delivered. Just as significantly, even if the message is delivered, a recipient may falsely deny receipt by claiming that ineffective techniques employed by an ISP provider blocked delivery. There is, therefore, a need for a method of verifying delivery of electronic messages.
Additionally, in many commercial applications where sensitive or confidential information will be forwarded in the message body, it is desirable to verify that the recipient and the Receiving Email System are available to receive the message before the email message content is forwarded. There is, therefore, a need for a method that verifies the recipient of an email message before the message is sent. Finally, in some commercial message applications, it is also desirable to vary the content of the message body being sent based on data related to the intended recipient. For example, if the recipient has indicated receptivity to offers for new credit cards with certain characteristics (e.g. an interest rate below a certain level or an available balance above a certain amount), the sender may desire to send a message body containing only compliant offers. There is, therefore, the need for a method which permits the sender of an email message to authenticate the recipient of an email message before the message content is forwarded and to allow the sender to vary message content based on data related to the intended recipient.
This applicant's U.S. application Ser. No. 10/803,120, filed Mar. 17, 2004, discloses an invention which permits a Receiving Email System to verify that an electronic message is authentic and not spoofed. Under the method disclosed in the application, a Sending Email System prepares a data record containing identifying information for each electronic message sent by the system. When a Receiving Email System receives an electronic message, it identifies the purported originating Sending Email System by referring to data in the email header and sends a confirmation request to that System. The confirmation request includes data from the email corresponding to the data which a Sending Email System uses to prepare data records for sent email. Where the email is authentic, the Sending Email System will receive the confirmation request and compare the data in the confirmation request with the data records it maintains for emails it has sent. When the Sending Email System locates a data record corresponding to the email identified by the data in the confirmation request, it will authenticate the email by replying to the Receiving Email System. Where the email has been spoofed, the Sending Email System will reply to the confirmation request by denying that it originated the email.
In a slightly different fashion, this applicant's and Leslie J. Kim's U.S. application Ser. No. 11/010,600 permits a Sending Email System to authenticate messages without maintaining a data record for each email sent. Under the method disclosed in the application, a Sending Email System prepares a data string by applying an algorithm to specified data elements of each email which it sends. It then appends the data string to the email and transmits the message with the data string to the intended recipient. A Receiving Email System which receives an email message first identifies the purported originating Sending Email System by referring to data in the email header and then sends a confirmation request to that System. The confirmation request includes the data string from the email message as well as the specified data elements from which the data string would have been prepared by a Sending Email System. The Sending Email System will receive the confirmation request and compute a second data string by applying the same algorithm to the data elements sent in the confirmation request. If the second data string is equivalent to the data string in the confirmation request, the Sending Email System will authenticate the email by replying to the Receiving Email System. Where the data strings are not equivalent (because, for example, the email received by the Receiving Email System has been spoofed), the Sending Email System will reply to the confirmation request by denying that it originated the email.
This applicant's PCT Application PCT/US05/35676 discloses a method by which data regarding phishing attempts may be collected for analysis, which is particularly useful where one of the verification methods disclosed in the earlier U.S. Applications is being practiced. However, even where one of the methods disclosed in U.S. application Ser. No. 10/803,120 or U.S. application Ser. No. 11/010,600 is employed, there is still a need for a method to authenticate the recipient of an electronic message before the message body is forwarded and which permits the sender to vary the message content based on data related to the intended recipient.